home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 1
/
Cream of the Crop 1.iso
/
UTILITY
/
TLB_V211.ARJ
/
LASTBYTE.DOC
< prev
next >
Wrap
Text File
|
1992-08-11
|
91KB
|
2,343 lines
THE LAST BYTE MEMORY MANAGER (tm)
An Upper Memory Manager for MS-DOS
Version 2.11
Copyright (C) 1990-92
All Rights Reserved
by
KEY SOFTWARE PRODUCTS
440 Ninth Avenue
Menlo Park, California 94025
415-364-9847
The Last Byte Memory Manager is a trademark of Key Software Products.
MS-DOS and Windows 3.0 are trademarks of Microsoft Corporation.
DR-DOS is a trademark of Digital Research Incorporated.
4DOS is a trademark of J.P. Software.
Hyperdisk is a trademark of HyperWare.
TABLE OF CONTENTS
CHAPTER 1 - INTRODUCTION ........................... 1
1.1 Seven Important Advantages ................... 1
CHAPTER 2 - GETTING A QUICK START ..................... 3
2.1 Checking Compatibility Using CHIPSET .......... 3
2.2 Making a Demo Diskette for Testing .............. 3
2.3 Viewing Upper Memory with HIGHMEM .............. 5
CHAPTER 3 - LASTBYTE.SYS COMMAND LINE OPTIONS ......... 7
3.1 BANKSWITCH=<base>:<size> ................... 7
3.2 CACHE=<kbytes> ............................. 8
3.3 DOS=<base>:<size> .......................... 8
3.4 EXCLUDE=<base>:<size> ...................... 8
3.5 KEY=<AccessKey> ............................ 8
3.6 MOVE=VIDEOBIOS ............................. 9
3.7 MOVE=MAINBIOS .............................. 9
3.7.1 The ADDHOLES suboption .................. 9
3.8 MOVE=OVERLAY ............................... 9
3.9 MOVE=XBDA .................................. 9
3.10 NAME=<RegisteredUserName> ................. 9
3.11 PHYSICAL=<MemoryController> ............... 10
3.11.1 The OVERRIDE suboption ................. 10
3.11.2 The NOEMS suboption .................... 10
3.12 RESTRICT=<ab> <cd> <ef> ..................... 10
3.13 SHADOW=<base>:<size> ...................... 11
3.14 TEXT=<Attribute> .......................... 12
3.15 The ? (question mark) Option .................. 12
CHAPTER 4 - HIGHDRVR AND HIGHTSR COMMAND LINE OPTIONS ... 13
4.1 HIGHDRVR Command Line Syntax .................. 13
4.2 HIGHTSR Command Line Syntax ................... 13
4.3 The /SIZE Option ............................. 14
4.4 Measuring Load Requirements Using /SIZE ........ 14
4.5 Achieving Best Fit Using /SIZE:n1 .............. 15
4.6 Borrowing Memory Using /SIZE:n1 n2 ............. 15
4.7 The /LOW Option .............................. 16
4.8 The /RESTRICT Option ......................... 16
4.9 The /!NOPAUSE Option ......................... 16
4.10 The /NOENV Option (HIGHTSR only) .............. 17
CHAPTER 5 - HIGHUMM.SYS: A UMB PROVIDER ............... 18
5.1 The /REPLACE Option .......................... 18
5.2 The /NOSPLIT Option .......................... 18
5.3 The /RESTRICT Option ......................... 19
5.4 Limiting UMB Memory .......................... 19
CHAPTER 6 - SPECIAL CONSIDERATIONS .................. 20
6.1 Specifying Command Line Options with Indirect Files 20
6.2 Using the DOS=F000:32 Option .................. 20
6.3 Video Display RAM above 640k ................... 21
TABLE OF CONTENTS
6.4 Video Adapter Bios ROMs ....................... 22
6.5 LASTBYTE.SYS and Expanded Memory .............. 22
6.6 Fine-Tuning your Adapter Hardware Configuration 23
CHAPTER 7 - USE WITH OTHER SOFTWARE ................... 25
7.1 Microsoft's FASTOPEN and MODE programs ......... 25
7.2 Microsoft's SHARE program .................... 25
7.3 Microsoft's MS-DOS 5.0 ....................... 26
7.3.1 Using DEVICEHIGH and LOADHIGH ............ 27
7.3.2 Using HIGHDRVR and HIGHTSR ............... 27
7.4 Microsoft Windows ........................... 28
7.4.1 Modifying the Windows SYSTEM.INI File ..... 28
7.4.2 Positioning an EMS Page Frame ............. 29
7.4.3 "Unsupported Data Configuration" ........ 29
7.4.4 HIGHMEM and Windows 386 Enhanced Mode ...... 30
7.5 HyperWare's HyperDisk ....................... 30
7.6 J.P. Software's 4DOS ......................... 30
7.7 David Hamilton's BUFFIT ...................... 31
7.8 Charles Lazo's WAS ........................... 31
7.9 Philip Gardner's DOSMAX ...................... 31
APPENDIX 1 - HOW TO REACH US .......................... 33
APPENDIX 2 - ACKNOWLEDGEMENTS ...................... 35
APPENDIX 3 - LIMITED WARRANTY ....................... 36
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 1
CHAPTER 1 - INTRODUCTION
The Last Byte Memory Manager is a collection of software that
can provide up to 384k of additional memory to your computer in
the upper memory area between 640k and 1 meg. It does this by
using shadow ram memory, existing fixed read/write (RAM) memory,
or by mapping expanded memory (EMS) pages into the upper area.
With The Last Byte Memory Manager, device drivers, terminate and
stay resident (TSR) programs, and more can be moved up into
upper memory, leaving more conventional memory available for
your application programs. Depending on your hardware, you may
also be able to extend the total conventional memory from 640k
to as much as 736k.
The Last Byte Memory Manager package also includes several
advanced utility programs that can move the master environment,
DOS FILES, DOS BUFFERS into upper memory. Other advanced
utilities create ram disks, print spoolers, command line recall
(history) buffers, emulated expanded memory, and TSR "markers"
(to facilitate TSR removal). Best of all, these utilities can
even use shadow ram memory which has been disabled (refered to
as "Bank-Switch" memory) by the presence of the display buffer,
unshadowed read-only memories (ROMs), and other adapter cards.
1.1 Seven Important Advantages
The Last Byte Memory Manager offers seven significant advantages
over other MS-DOS Upper Memory Managers:
1. The Last Byte Memory Manager leaves no "stubs" in
conventional memory.
2. The Last Byte Memory Manager will work with any
processor chip, even the 8088 used in the original
IBM PC. Many memory managers require a 386 cpu or
better.
3. The Last Byte Memory Manager doesn't use protected
mode. Unlike those memory managers that do, The
Last Byte Memory Manager is totally compatible
with any protected mode software, not just
Microsoft Windows.
4. The Last Byte Memory Manager doesn't require any
extended memory. Some memory managers depend on
the processor's ability to remap physical memory
from above 1MB into the upper memory area.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 2
5. On motherboards that use one of the supported
memory controller chips, The Last Byte Memory
Manager, unlike all other memory managers, can use
the unused shadow ram normally disabled by the
display buffer, unshadowed ROMs or adapter cards.
This gives it the unique ability to use all 384k
of upper memory!
6. The Last Byte Memory Manager does not slow down
the performance of your computer, because it does
not incur the 5-10% execution overhead inherent in
protected mode.
7. On motherboards that use one of the supported
memory controller chips, The Last Byte Memory
Manager can extend conventional memory using
regular full-speed motherboard memory rather than
using the EGA/VGA display buffer. (The display
buffer memory of some EGA/VGA adapter cards can be
as much as six times slower than regular memory.)
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 3
CHAPTER 2 - GETTING A QUICK START
The first thing to do is to be sure that The Last Byte Memory
Manager will work on your computer. Fundamentally, the
requirements are DOS version 3.1 or later and some method of
implementing memory in the upper memory area between 640k and 1
meg. Any Intel (or Intel-compatible) processor will do,
including the original Intel 8088 cpu. No extended memory is
required.
2.1 Checking Compatibility Using CHIPSET
The CHIPSET program is designed to determine if The Last Byte
Memory Manager is compatible with your computer. To run
CHIPSET, simply enter its name on the command line:
A>CHIPSET
If successful, CHIPSET will give you the option of automatically
linking to the INSTALL program to either create a demo diskette
(as described below) or to install the software on your hard
disk. For more detailed information on the CHIPSET program and
system requirements, consult the file CHIPSET.DOC.
2.2 Making a Demo Diskette for Testing
To install The Last Byte Memory Manager on a floppy diskette for
testing, perform the following three steps:
Step 1: Use the MS-DOS FORMAT command with the /S
option to prepare a bootable floppy disk.
You will need this in Step 2.
Step 2: Run the CHIPSET program. If it succeeds, it
will ask you "Do you want to run the INSTALL
program now?". Answer yes. When it displays
the first screen of the INSTALL program,
select the first option, "Creating a
demonstration diskette" and follow the
prompts.
Step 3: Once you have created your demonstration
diskette, press Ctrl-Alt-Del to reboot your
computer from the diskette.
When your computer reboots, LASTBYTE.SYS will pause thirty
seconds and then require a keypress to proceed. The pause and
the keypress are removed when you purchase and install an access
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 4
key (see ORDERFRM.DOC). There are, however, no other
restrictions on the unlicensed version - it is a fully
functional version of the software.
If everything goes ok during the boot, you'll see a sign-on box
that looks something like the following:
╔═══════════════════════════════════════════════════════════════════╗
║ THE LAST BYTE MEMORY MANAGER (tm) Version 2.11a ║
║ Copyright (C) 1990-92, Key Software Products, All Rights Reserved ║
║ « You can LICENSE a copy of this software for only $29.95! » ║
╟───────────────────────────────────────────────────────────────────╢
║ 50.0 Mhz 80486 with 256KB Cache and OPTi Electronics 82C495 ║
╟───────────────────────────────────────────────────────────────────╢
║ Address Range Size Width Bandwidth Description ║
║ 256 KB 128 bits 200.0 MB/Sec Secondary CPU Cache ║
║ 00000-9FFFF 640 KB 32 bits 97.6 MB/Sec Conventional Memory ║
║ C0000-EFFFF 192 KB 32 bits 97.6 MB/Sec Shadow Ram Memory ║
║ A0000-AFFFF 64 KB 16 bits 1.7 MB/Sec VGA Graphics Buffer ║
║ B8000-BFFFF 32 KB 16 bits 1.7 MB/Sec VGA Color Text Bfr ║
║ C0000-C7FFF 32 KB 8 bits 1.2 MB/Sec VGA Adapter Bios ║
║ C8000-C97FF 6 KB 8 bits 1.2 MB/Sec Fixed Disk Bios ║
║ C9800-C9BFF 1 KB 8 bits 1.2 MB/Sec Fixed Disk Ram ║
║ F0000-FFFFF 64 KB 8 bits 2.0 MB/Sec AMI Bios (06/06/91) ║
╟───────────────────────────────────────────────────────────────────╢
║ Conv:640k High-DOS:144k Bank-Switch:16k Shadowed:96k Excluded:128k║
╟───────────────────────────────────────────────────────────────────╢
║ The Last Byte Memory Manager is a trademark of Key Software Prod. ║
╚═══════════════════════════════════════════════════════════════════╝
If your computer stops before displaying the box shown above, or
if it fails to operate properly after booting, there are two
possible reasons:
1. CHIPSET identified the wrong memory controller.
Try running CHIPSET again, and this time manually
test each of the menu options, noting if more than
one chipset is identified. If so, then run the
INSTALL program again for one of the other
chipsets that it finds.
2. The Last Byte Memory Manager failed to recognize
one of your installed adapters that uses some
portion of the upper memory address space. If
this happens, you'll probably need to use an
EXCLUDE option on the LASTBYTE.SYS command line to
manually disable the corresponding region(s) where
conflict occurs.
To temporarily get around either of these problems, you can
reboot and manually bypass execution of all The Last Byte Memory
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 5
Manager software by simultaneously holding down the <alt> key,
the <ctrl> key, and either the <leftshift> or <rightshift> key
during the boot sequence.
If The Last Byte Memory Manager installs and AUTOEXEC.BAT
finishes properly, then your display will be filled with the
output of the HIGHMEM program and the current time will be
displayed in inverse video in the upper left-hand corner. This
verifies that HIGHTSR has successfully loaded both the device
driver ANSI.SYS and the TSR program CLOCK.EXE into upper memory
and that they are operating properly.
To exit from HIGHMEM, simply press the Esc key.
Once you are convinced that The Last Byte Memory Manager is
working satisfactorily, you may install it on your hard disk by
making drive C: the current drive by entering
C:
and rerunning CHIPSET or INSTALL.
2.3 Viewing Upper Memory with HIGHMEM
Depending on what adapter cards you have installed, HIGHMEM's
output should look something like that shown below.
Bracketed numbers in the High-DOS column (e.g., "[141,136]")
indicate free memory that is available for additional device
drivers and TSRs. Bracketed numbers in the "Bank-Switch" column
(if any) indicate free memory that can be used by some of the
advanced utilities contained in the file TLB-A211.ZIP; this
memory can be used to implement a ram disk, a print spooler,
emulated EMS memory, or TSR markers.
Note: HIGHMEM automatically senses whether you have a color or
monochrome display to determine how to present data on the
screen. However, you may force the mode using one of the /MONO,
/COLOR, or /LCD command line options.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 6
HIGHMEM v2.11a (C) Key Software Products 1990-92. All Rights Reserved.
MCB Hex Address Description [Type] <Mark> High-DOS Bnk-Swtch Total
──── ─────────── ───────────────────────── ──────── ───────── ───────
CC00 A0000-CBFFF Reserved Memory Group
CC02 A0000-AFFFF ╠═16-bit VGA Graphics Buffer 65,536
CC04 B0000-B7FFF ╠═Unavailable 32,768
CC06 B8000-BFFFF ╠═16-bit VGA Color Text Buffer 32,768
CC08 C0000-C7FFF ╠═Shadowed 8-bit VGA Bios Rom 32,768
CC0A C8000-C97FF ╠═8-bit Fixed Disk Adapter Bios [ 6,144][ 6,144]
CC0C C9800-C9BFF ╠═8-bit Fixed Disk Adapter Ram [ 1,024][ 1,024]
CC0E C9C00-CBFFF ╚═DOS Unusable [ 9,216][ 9,216]
CC10 CC110-CC54F LASTBYTE [DEV] 1,088 1,088
CC55 CC560-CD5BF ANSI [DEV] 4,192 4,192
CD5C CD5D0-CD6CF CLOCK [ENV] 256 256
CD6D CD6E0-CD88F CLOCK [TSR] 432 432
CD89 CD8A0-EFFEF [∙∙∙Free∙∙∙] [141,136] [141,136]
EFFF F0000-FFFFF Shadowed 8-bit AMI Bios Main Bios 65,536
─────── ─────── ───────
Upper Memory In Use: 5,968 0 235,344
[Free Upper Memory]: 141,136 16,384 157,520
MCB Overhead: 352 n/a 352
[No HMA Configured] ─────── ─────── ───────
Total Upper Memory: 147,456 16,384 393,216
The following article provides an excellent definition of the
various kinds of memory, such as conventional, extended,
expanded, high, and upper. More important, however, is its
discussion of how various adapter cards make use of the upper
address space, and may provide some insight if you're having
problems getting The Last Byte Memory Manager to install
properly:
Barry Simon, "How to Get the Most from Your System's
High DOS Memory", PC Magazine, Vol. 9, No. 10 (May 29,
1990), pp. 347-358.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 7
CHAPTER 3 - LASTBYTE.SYS COMMAND LINE OPTIONS
During initialization, LASTBYTE.SYS scans upper memory looking
for Bios ROMs, the video display buffer, and adapter cards that
use some portion of the upper memory address space. Of the
upper memory available on your computer, the unoccupied portion
defaults to High-DOS memory, and the occupied portion defaults
to Bank-Switch memory.
These defaults can be modified by the use of command line
options. There are several command line options for
LASTBYTE.SYS. Many of these use a format like:
<keyword>=<base>:<size>
where <keyword> is one of the option keywords and may be
abbreviated by its first letter, <base> is a four-digit
hexadecimal segment address in the range A000 to FC00, and
<size> is a decimal number in kilobytes.
There are two restrictions on these options:
1. The base must be exactly 4 hexadecimal digits,
must lie at or above A000, and must be a multiple
of 0020 (512 bytes), and
2. The size must be in the range 1-384 kb.
The "multiple of 0020" requirement for the base is necessary to
be consistent with the resolution that The Last Byte Memory
Manager uses to organize high memory during initialization.
However, this requirement is often affected by the much coarser
resolution used by most memory controllers.
The upper area is partitioned into blocks. Some controllers use
16k blocks, some use 32k blocks, and some use 64k blocks. Each
block must be either totally enabled or disabled. I.e., if any
part of a block's address space is disabled by the presence of
an adapter card, the entire block of memory is disabled and
cannot be made available as High-DOS Memory.
3.1 BANKSWITCH=<base>:<size>
Forces a region of upper memory that would normally be used as
High-DOS memory to be made available as Bank-Switch memory.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 8
┌─────────────────────────────────────────────────┐
│ This option requires a memory controller chip. │
└─────────────────────────────────────────────────┘
3.2 CACHE=<kbytes>
Forces LASTBYTE.SYS to think that there is a cache between the
CPU and main memory and to set its size. (This has nothing to
do with disk caching!) This option is not normally necessary;
LASTBYTE.SYS normally will automatically detect the presence of
a cache and its size.
Activating bank-switch memory causes the contents of a cache (if
present) to be invalid; this is known as a "cache coherency"
problem. If a cache is detected during installation,
LASTBYTE.SYS checks to see if any portion of the upper address
space is cached. If not, then no cache coherency problem
exists.
If the upper address space is cached, however, LASTBYTE.SYS will
flush the cache on every access to Bank-Switch memory in order
to prevent the cache from providing invalid data to the CPU.
The cache is flushed by filling it from low memory. The <size>
value is used to determine how much to fill.
3.3 DOS=<base>:<size>
Forces a region of upper memory that would normally be used as
Bank-Switch memory to be made available as High-DOS memory.
3.4 EXCLUDE=<base>:<size>
Forces a region of upper memory unavailable as either High-DOS
or Bank-Switch memory.
3.5 KEY=<AccessKey>
When you register The Last Byte Memory Manager, you are given an
access key that is derived from the spelling of your name. This
eight character key should be specified using this option, as
in:
KEY=12345678
This option must be used in conjunction with the NAME option
discussed below.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 9
3.6 MOVE=VIDEOBIOS
Tries to move an EGA or VGA bios to a better location within the
available upper memory in order to reduce fragmentation of free
memory.
3.7 MOVE=MAINBIOS
Tries to move the main bios to a better location within the
available upper memory in order to reduce fragmentation of free
memory.
3.7.1 The ADDHOLES suboption
MOVE=MAINBIOS,ADDHOLES will create seven holes in the residual
8k left at FE00 for a total of more than 3k.
3.8 MOVE=OVERLAY
This option is for chipsets in which the main bios shadow ram
cannot be made read/write (ETEQ, OPTi, Intel, and some by
VLSI). This option puts that ram in write-only mode, copies the
video bios on top of the main bios initialization code at the
beginning of the bios, then returns the ram to read-only mode.
Then the old video bios region is converted to usable Hi-DOS
memory.
3.9 MOVE=XBDA
This option relocates the Extended Bios Data Area (XBDA), if it
exists, into Upper Memory. The XBDA is usually 1k reserved at
the top of conventional memory by the main Bios. Not all
machines use an XBDA, but if it exists, LASTBYTE.SYS will report
639k of Conventional Memory instead of 640k, and the advanced
utility HIGHAPND will refuse to append any memory. Some
machines may not operate properly with a relocated XBDA, so use
this option with caution. (Note that some computer viruses also
"steal" the top 1k of memory.)
3.10 NAME=<RegisteredUserName>
When you register The Last Byte Memory Manager, you are given an
access key that is derived from the spelling of your name. This
option is used to specify your name as used to generate that
key, as in:
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 10
NAME=Daniel_W._Lewis
┌─────────────────────────────────────────────────┐
│ Note: Spaces MUST be indicated by underscores! │
└─────────────────────────────────────────────────┘
This option should be used in conjunction with the KEY option
discussed earlier.
3.11 PHYSICAL=<MemoryController>
Used to specify the memory controller determined by the CHIPSET
program.
3.11.1 The OVERRIDE suboption
Many memory controller chips can relocate all or part of shadow
ram to the top of (extended) memory. If LASTBYTE.SYS fails to
install with the error message:
"Shadow Ram memory relocated - Use OVERRIDE option"
try adding the OVERRIDE suboption to the PHYSICAL option, as in:
PHYSICAL=82C212,OVERRIDE
This disables any shadow ram relocation that may be in effect,
regardless of your CMOS configuration menu setup. The CMOS
setup menu of your BIOS may also provide an option to disable
relocation directly, but there are some that determine whether
to relocate or not based on other configuration options.
3.11.2 The NOEMS suboption
May be used in conjunction with PHYSICAL=LIM4EMS or EEMS to use
the 64k page frame as High-DOS Memory, as in:
PHYSICAL=LIM4EMS,NOEMS
The NOEMS suboption must be used in conjunction with
PHYSICAL=LIM3EMS (i.e., PHYSICAL=LIM3EMS,NOEMS). Doing so
disables other (normal) use of all expanded memory.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 11
3.12 RESTRICT=<ab> <cd> <ef>
Address lines A15 and A16 are not latched in hardware design of
the AT bus. As a consequence, some 16-bit adapter cards do not
properly decode these address lines within the narrow time
constraints imposed by the Address Latch Enable (ALE) signal,
and will occassionally respond to a memory access that is
directed at some other portion of the address space. Thinking
that it is for them, they force the transfer into 16-bit mode
even though the intended recipient requires 8-bit mode, and thus
cause erroneous data to be transferred to the bytes in the
odd-numbered addresses.
The most common (and damaging) occurence occurs during the 8-bit
DMA transfers between a floppy disk drive and upper memory near
the address space occupied by an offending 16-bit adapter card.
Due to organization of the address signals on the AT bus, this
phenomena only occurs when the two address areas are within the
same 128k region. There are three such regions in the upper
area: A0000-BFFFF, C0000-DFFFF, and E0000-FFFFF. LASTBYTE.SYS
automatically senses the presence of 16-bit adapter cards in
each of these three regions and records this information within
its resident image for use by its utilities. LASTBYTE.SYS skips
this test if it detects a PC with a Micro Channel bus (like the
PS/2) since problem was corrected in its design.
The RESTRICT option is provided to override this automatic
detection of 16-bit adapters. Each of the three arguments (one
per 128k region) should be replaced by either "0" (indicating no
16-bit adapters), or "1" (indicating the presense of a 16-bit
adapter) and separated by commas.
For example, the option RESTRICT=1,1,0 would imply that one or
more 16-bit adapters are located in the first two 128k regions
of upper memory (A000-DFFF), so that when the companion
/RESTRICT option of HIGHDRVR, HIGHTSR, or HIGHUMM is used, only
High-DOS memory in the region E000-FFFF will be allocated.
(Note: The /RESTRICT option is also supported by the advanced
utilities HIGHEMS3, and HIGHEMS4. The default operation of the
advanced utility HIGHBFRS is /RESTRICT, but this may be disabled
by use of its /NORESTRICT option.)
3.13 SHADOW=<base>:<size>
The Last Byte Memory Manager will automatically copy the video
bios and main bios to shadow ram if they aren't already
shadowed. However, it will not do so for other adapter ROMs.
This is because some controllers "hide" a small RAM by
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 12
overlaying it in a portion of the same address space they
declare as being filled with ROM. Such a RAM is no longer
accessible when the ROM is shadowed, usually causing the adapter
to stop functioning.
This option is for those who want to forces a region of memory
(presumably ROM) to be copied into shadow ram. If other
hardware is detected outside the specified region, but within
the same memory controller block which conflicts with this
request, a corresponding error message will be displayed and
LASTBYTE.SYS will not be installed.
┌─────────────────────────────────────────────────┐
│ This option requires a memory controller chip. │
└─────────────────────────────────────────────────┘
3.14 TEXT=<Attribute>
The information screen invoked by the "?" option defaults to
bright white on blue if a color display is active, and to
inverse video if a monochrome monitor is active. This option
changes the default to the parameter value specified, where
<Attribute> is the hexadecimal value of the attribute byte used
to paint the screen.
3.15 The ? (question mark) Option
Causes LASTBYTE.SYS to erase the screen, display a summary of
what it finds in the upper memory area, and pause for two
seconds to give the user an opportunity to read the
information. To freeze this display for a longer period, press
<Ctrl>-S; then to continue with CONFIG.SYS processing, press any
key.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 13
CHAPTER 4 - HIGHDRVR AND HIGHTSR COMMAND LINE OPTIONS
HIGHDRVR is a device driver that is used to load other device
drivers into upper memory. HIGHTSR is a program that is used to
load TSR programs into upper memory. Both utilities use most of
the same command line options as discussed in the sections that
follow.
4.1 HIGHDRVR Command Line Syntax
The command line syntax of the CONFIG.SYS line for HIGHDRVR is:
DEVICE=[path]HIGHDRVR.SYS [options] <filespec> [options]
where '<filespec>' is the filename of the device driver to be
loaded high, optionally prefixed by a drive and directory
specifcation. The filespec may be preceded by one or more
options, and followed by options at the end of the command line
as required by the particular driver to be loaded.
When HIGHDRVR searches the disk for the device driver to load,
it follows the following search strategy:
1. If '<filespec>' includes a drive or directory
specification, this will be the only place that
HIGHDRVR will look.
Otherwise, HIGHDRVR will search for the driver in:
2. The current (root) directory, and then
3. The same directory where HIGHDRVR was found.
4.2 HIGHTSR Command Line Syntax
The command line syntax for HIGHTSR is:
[path]HIGHTSR [options] <filespec> [options]
where '<filespec>' is the filename of the TSR program to be
loaded high, optionally prefixed by a drive and directory
specifcation. The filespec may be preceded by one or more
options, and followed by options at the end of the command line
as required by the particular TSR to be loaded.
When HIGHTSR searches the disk for the device driver to load, it
follows the same strategy that MS-DOS uses when loading
programs:
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 14
1. If '<filespec>' includes a drive or directory
specification, this will be the only place that
HIGHTSR will look.
Otherwise, HIGHTSR will search for the TSR program in:
2. The current directory, and then
3. Those directories given by the PATH environment
variable.
HIGHTSR may also be used with the MS-DOS "INSTALL=" directive of
a CONFIG.SYS file.
4.3 The /SIZE Option
The amount of High-DOS memory required to load a device driver
or TSR is the larger of two amounts: (1) the amount required
during initialization and (2) the final resident requirement
once installed. Either or both of these may be greater than or
equal to the size of the file.
Most device drivers and TSR's require more memory for
initialization than when resident, although there are a few
(such as SMARTDRV.SYS and NANSI.SYS) which require extra
resident memory for buffers, etc. The normal operation of
HIGHDRVR and HIGHTSR is to use the largest free High-DOS memory
block to load the software since the resident memory requirement
cannot be determined until after the software has been loaded
and initialized.
Unfortunately, this can lead to a less than optimum use of
memory. If the memory requirements were known, then a memory
block could be selected using a "best fit" strategy; i.e., the
smallest free High-DOS memory block which is larger than or
equal to the load requirement. This usually results in much
better utilization of memory.
4.4 Measuring Load Requirements Using /SIZE
If inserted on the command line of HIGHTSR or HIGHDRVR as shown
below:
HIGHTSR /SIZE PRINT /D:PRN
-or-
DEVICE=HIGHDRVR.SYS /SIZE ANSI.SYS
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 15
then both the initialization and resident requirements will be
displayed on the console after the software has been loaded and
initialized.
4.5 Achieving Best Fit Using /SIZE:n1
The larger of the initialization and resident requirements may
be specified with the /SIZE option to force a "best fit"
allocation. For example:
HIGHTSR /SIZE:17120 PRINT.EXE /D:PRN
-or-
DEVICE=HIGHDRVR.SYS /SIZE:12032 ANSI.SYS
4.6 Borrowing Memory Using /SIZE:n1 n2
Usually the resident requirement is less than the initialization
requirement. If there isn't enough free High-DOS memory to
satisfy the initialization requirement, but there is enough for
the resident requirement, then you may still be able to load
your software by adding a second parameter to the /SIZE option,
as in:
HIGHTSR /SIZE:16208,5776 PRINT /D:PRN
-or-
DEVICE=HIGHDRVR.SYS /SIZE:12032,4820 ANSI.SYS
In this example, the initialization requirement is specified by
the first parameter and is 16208 bytes; the resident requirement
is specified by the second parameter and is 5776 bytes. Note
that specifying the second parameter is not helpful unless the
resident requirement is less than the initialization
requirement.
When the second parameter is used, HIGHTSR first looks for a
free area larger than or equal to the initialization requirement
(the first parameter); if found, it simply loads the software in
this area and the second paramter is ignored. Otherwise,
HIGHTSR searches for a free area larger than or equal to the
resident requirement (the second parameter), and which has
"data" allocated immediately above it that can be temporarily
moved to create enough free memory to satisfy the initialization
requirement. Such "data" includes High-DOS memory used by the
advanced utilities HIGHDISK, HIGHEMS3, HIGHEMS4, HIGHSPLR,
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 16
HIGHKEY, and HIGMARK.
4.7 The /LOW Option
As noted earlier, TSR's and device drivers often require much
more memory during installation as compared to that required
once they are resident. This can prevent loading them into
High-DOS memory even if there's enough for the resident image
(but not enough for initialization).
The /LOW option can be used with some TSR's and device drivers
to get around this problem:
HIGHTSR /LOW APPEND
-or-
DEVICE=HIGHDRVR.SYS /LOW MYDRIVER.SYS
For example, the first example above loads a TSR (APPEND.EXE)
and initializes it in low (conventional) memory where there's
lots of room, then copies the (smaller) resident image up into
upper memory.
╔═════════════════════════════════════════════════╗
║ WARNING: The design of some software may pre- ║
║ vent the /LOW option from working properly. ║
║ Don't use it unless necessary, and then only ║
║ after you have tested it to be sure everything ║
║ works as expected. (For example, it will NOT ║
║ work with PRINT, SHARE, FASTOPEN, MODE, or ║
║ HyperDisk.) ║
╚═════════════════════════════════════════════════╝
4.8 The /RESTRICT Option
When used, this option restricts which 128k regions of upper
memory may be allocated for use with HIGHDRVR and HIGHTSR. For
a detailed discussion of why these regions may need to be
restricted and how to control the restrictions, see the
discussion of the RESTRICT option in the detailed description of
LASTBYTE.SYS.
4.9 The /!NOPAUSE Option
All of the utility programs (*.EXE files) that come with The
Last Byte Memory Manager support the command line option
/!NOPAUSE. This option eliminates the wait-for-keyboard pause
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 17
after an error message is displayed. When one of these programs
terminates with an error message, it also returns a non-zero
errorlevel which can be tested in batch files to make automatic
decisions about how to proceed. The /!NOPAUSE option simply
makes use of the errorlevel more practical.
4.10 The /NOENV Option (HIGHTSR only)
All programs, including TSR's, are allocated two regions of
memory when they are loaded: One is the area for the program
itself, and the other is for a copy of the environment. Most
TSR's don't make use of their environment, and some actually
release it to the operating system rather than hanging onto it.
If HIGHMEM finds an environment block, the corresponding entry
in the "Description" column will have the name of the TSR that
it belongs to (such as "CLOCK.EXE") followed by the indication
"[Env]". Occassionally, you may see a similar indication
"[Dat]"; this is a data block explicitly allocated by the TSR
for some unknown purpose.
┌─────────────────────────────────────────────────┐
│ The authors of some TSR's attempt to save a bit │
│ of memory by having the TSR eliminate its own │
│ Program Segment Prefix (PSP) during initializa- │
│ tion. Doing so makes it impossible to identify │
│ the TSR'senvironment block. However, this byte │
│ saving mentality will usually mean that the TSR │
│ initialization code also eliminates its environ-│
│ ment block, so this is rarely a problem. │
└─────────────────────────────────────────────────┘
If you see a block labelled "[Env]" in the output of HIGHMEM,
then you can use the /NOENV command line option of HIGHTSR to
release this block, even if the TSR didn't:
HIGHTSR /NOENV CLOCK
As noted earlier, some TSRs will release their environment
anyway and so you may be tempted to load them without using the
/NOENV option. This usually will create a "hole" in upper
memory since the TSR's environment is almost always allocated
just below the TSR itself. Use of the /NOENV option forces the
environment to be allocated down in conventional memory (where
it will be reclaimed later) so that the "hole" is eliminated.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 18
CHAPTER 5 - HIGHUMM.SYS: A UMB PROVIDER
HIGHUMM is a device driver that creates, and lets application
software use, Upper Memory Blocks (UMB's) in the upper memory
area via a standard protocol that is part of what is known as
the Extended Memory Specification (XMS). The number, size, and
location of UMB blocks vary widely depending upon the types of
hardware adapter cards resident within the upper address space.
If HIGHUMM is installed, you may use the DOS 5 DEVICEHIGH and
LOADHIGH commands as alternatives to HIGHDRVR and HIGHTSR.
HIGHUMM can also be used to advantage with other software such
as 4DOS, BUFFIT, WAS, and DOSMAX. These options are discussed
in the next chapter.
HIGHUMM may be installed in one of two ways:
1. If an XMS driver has not been loaded, HIGHUMM will
become a UMB-Only XMS device driver. All other
XMS functions will return failure, indicating that
the function is not implemented. For example,
DEVICE=LASTBYTE.SYS {and any LASTBYTE options}
DEVICE=HIGHUMM.SYS
2. If an XMS driver (such as HIMEM.SYS) has already
been loaded, HIGHUMM will link into it, adding the
UMB functions. For example:
DEVICE=LASTBYTE.SYS {and any options}
DEVICE=HIGHDRVR.SYS C:\DOS\HIMEM.SYS {and any options}
DEVICE=HIGHUMM.SYS
Do not install HIGHUMM using either HIGHDRVR or the DEVICEHIGH
command; simply use a DEVICE command, as shown above.
5.1 The /REPLACE Option
Although described in the XMS specification, most XMS device
drivers so not implement the UMB functions. If your XMS driver
happens to also be a UMB provider, HIGHUMM will abort with a
corresponding error message. You may then use the /REPLACE
option on the HIGHUMM.SYS command line to force it to take over
responsibility for providing UMBs.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 19
5.2 The /NOSPLIT Option
HIGHUMM requires that LASTBYTE.SYS be installed first. It
automatically loads itself into upper memory, putting much of
itself into Bank-Switch memory if available. (You can prevent
this by using the /NOSPLIT option.)
5.3 The /RESTRICT Option
When used, this option restricts which 128k regions of upper
memory may be allocated for use with HIGHUMM. For a detailed
discussion of why these regions may need to be restricted and
how to control the restrictions, see the discussion of the
RESTRICT option in the chapter on LASTBYTE.SYS.
5.4 Limiting UMB Memory
If you want to limit how much upper memory can be allocated by
HIGHUMM as UMB's, you can specify this in kbytes as an option on
the HIGHUMM.SYS command line, as in:
DEVICE=HIGHUMM.SYS 60
This provides a guarantee that some amount of upper memory will
never be allocated by HIGHUMM.SYS, and will thus still be
available for other uses.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 20
CHAPTER 6 - SPECIAL CONSIDERATIONS
6.1 Specifying Command Line Options with Indirect Files
Some of the device drivers and utility programs in The Last Byte
Memory Manager package may require lots of options to be
specified. To avoid lengthly command lines, these options can
be placed in a text file if the name of that file is specified
on the command line preceded by the '@' character. For example,
you'd begin to run out of room if all of the following options
were required on the LASTBYTE.SYS command line:
PHYSICAL=82C302 NAME=Joe_Blow KEY=12345678 APPEND=64 DOS=F000:32 ?
As an alternative, create a corresponding text file called
LASTBYTE.CFG (for example), and put the options into it:
PHYSICAL=82C302 NAME=Joe_Blow KEY=12345678 APPEND=64
DOS=F000:32 ?
(Carriage returns in the indirect file are treated as blanks)
Then the CONFIG.SYS command line becomes simply:
DEVICE=LASTBYTE.SYS @LASTBYTE.CFG
In effect, options taken from the indirect file are inserted
into the command line, so that one or more indirect file
references may be placed among other options on the command
line:
DEVICE=LASTBYTE.SYS ? @TLB.1 A=32 @C:\TLB\TLB.2
Indirect files may be used on the command line of any device
driver (.SYS files) or utility program (.EXE files) in The Last
Byte Memory Manager package.
6.2 Using the DOS=F000:32 Option
The 64k region starting at paragraph address F000 is the Bios
ROM. Many computers use a Bios ROM developed by AMI or
Phoenix. The more recent versions of these ROMs devote the
first 32k to initialization code that is only used during the
boot sequence, and use the second 32k for that portion that must
remain available at all times. (This seems to be true of the
Award Bios as well, but has not been verified.)
By the time your computer gets to the point in its boot sequence
where it is installing the device drivers (e.g., when it is
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 21
installing LASTBYTE.SYS), the Bios initialization code is no
longer needed. If you have one of these AMI or Phoenix Bios
chips, you can capture another 32k of upper memory by using a
DOS=F000:32 option on the LASTBYTE.SYS command line.
Of course, whenever you press Ctrl-Alt-Del to do a warm boot,
the ROM Bios initialization code needs to be executed again!
And that could be a problem since you've effectively disabled it
with the DOS=F000:32 option! Fortunately, LASTBYTE.SYS
intercepts all keyboard input and keeps an eye out for
Ctrl-Alt-Del. When it sees the warm boot request, it will force
a cold boot if you've used the DOS=F000:32 option. This
re-enables the entire 64k Bios ROM so that the initialization
code is reactivated before the processor tries to execute it.
Otherwise a normal warm boot is used.
╔═════════════════════════════════════════════════╗
║ WARNING: Some TSRs intercept keyboard interrupt ║
║ 9, and jump directly into a fixed location in ║
║ the Bios ROM where the Warm Boot code begins. ║
║ Unfortunately, this will bypass LASTBYTE.SYS's ║
║ attempt to turn the ROM back on. ║
╚═════════════════════════════════════════════════╝
6.3 Video Display RAM above 640k
In general, the region A0000-BFFFF is the video display buffer
area. Various display adapters (MDA, Hercules, CGA, EGA, and
VGA) typically use only a small subset of this space. The Last
Byte Memory Manager automatically senses what kind of video
display adapter is installed and reserves the space it uses.
The MDA (monochrome) adapter implements a 4k text buffer at
B0000-B0FFF, and the CGA (color) adapter implements a 16k text
and graphics buffer at B8000-BBFFF. The Hercules adapter uses
the entire 64k region at B0000-BFFFF in graphics modes, although
only the first 4k of this space (B0000-B0FFF) is used for text
modes.
The EGA and VGA adapters have a 64k graphics display buffer at
A0000-AFFFF, and a 32k text display buffer at either B0000-B7FFF
(when used with a monochrome display), or at B8000-BFFFF (when
used with a color display).
The following chart summarizes these regions as well as some of
the DOS and APPEND optons you may be able to use on the
LASTBYTE.SYS command line with these adapters. Unfortunately,
the ROM bios on a (very) few PC's may write into locations
outside the area reserved for a particular type of display. If
you decide this is happening, you may need to add one or more
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 22
EXCLUDE options to the LASTBYTE.SYS command line to disable that
region.
LASTBYTE.SYS Command Line Options for Display Adapters
Adapter Reserved DOS APPEND
------- -------- ------- -------
CGA B800:16 96
MDA B000:4 64
Hercules B000:64 B400:48 64
EGA/VGA A000:64 BC00:16 96
w/Color B800:32
Display
EGA/VGA A000:64 B400:16 64
w/Mono B000:32
Display
VGA Bios C000:32 C600:8 (see next section)
Notes: (1) Windows 3.0 may write in the region B000-BFFF.
(2) The ability to use the DOS and APPEND options
depends on the availability of memory in the
indicated region.
6.4 Video Adapter Bios ROMs
MDA and CGA use the standard ROM Bios; they have no ROM of their
own. EGA and VGA adapters, however, incorporate their own ROM
Bios chip right on the adapter card. LASTBYTE.SYS successfully
recognizes these ROMs, but has to treat VGA in a special manner:
The VGA adapter made by IBM has a 24k ROM installed at
C0000-C5FFF, which means that the 8k at C6000-C7FFF should be
usable. Although almost all VGA clones have a ROM signature
that indicates 24k, many of them use the C6000-C7FFF space for
ROM Bios or RAM extensions that provide their "Super VGA"
features. In particular, the Video7 and Paradise VGA's
incorporate their own RAM from C6000-C7FFF. (This may also be
true of other VGA boards that uses a VLSI chip manufactured by
Chips and Technologies, Tseng Labs, Paradise, or Headland
Technologies.) For this reason, when LASTBYTE.SYS finds
anybody's VGA adapter, it automatically assumes that there is a
32k ROM at C0000-C7FFF.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 23
6.5 LASTBYTE.SYS and Expanded Memory
Expanded memory always has an associated device driver. If that
driver is loaded before LASTBYTE.SYS in the CONFIG.SYS file (and
if the hardware is enabled) LASTBYTE.SYS will recognize the 64k
EMM page frame of the expanded memory and do the right thing: It
will treat the page frame like any other adapter ram and disable
the motherboard RAM that falls in the same address space so that
it doesn't interfere with the page frame. For example, if the
EMM driver is loaded first, LASTBYTE.SYS will report the 64k EMM
page frame as "EMS Page Frame".
This works fine, of course, but loading the EMM driver first
precludes the possibility of loading it into upper memory. To
get the EMM driver into upper memory means that it must be
loaded after LASTBYTE.SYS, but you must be careful!
If LASTBYTE.SYS is loaded first, the page frame will be
recognized only in two cases:
1. The page frame used by the expanded memory
controller built into some memory controller chips
will be recognized and reported as "EMS Page
Frame".
2. The page frame of a REAL expanded memory board is
(if enabled) recognized and reported as "Adapter
RAM".
In either case, LASTBYTE.SYS will not use that memory space.
╔═════════════════════════════════════════════════╗
║ WARNING: Some EMS boards must be enabled by ║
║ their device driver before they respond as ║
║ read/write memory. This prevents LASTBYTE.SYS ║
║ from recognizing them, and you may need a ║
║ BANKSWITCH option to keep LASTBYTE.SYS from ║
║ using the page frame memory space. ║
╚═════════════════════════════════════════════════╝
If you don't have an expanded memory board, but have used a
device driver (like EMM386) that EMULATES expanded memory using
extended memory, then LASTBYTE.SYS will not know about the page
frame unless the emulator is loaded first. If LASTBYTE.SYS is
loaded first, then you must use a EXCLUDE (not BANKSWITCH!)
command line option of LASTBYTE.SYS to reserve a 64k region
where the emulated page frame can be placed. For EMM386, the
page frame must be positioned at C000, C400, C800, CC00, D000,
D400, D800, DC00, or E000.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 24
6.6 Fine-Tuning your Adapter Hardware Configuration
Many adapter cards occupy some portion of the upper address
space. Some of these cards, such as SCSI Disk Controllers,
often have DIP switches or jumpers that can be used to set the
address space they occupy to one of a few alternatives.
If the memory map displayed by HIGHMEM is fragmented because one
of these adapters sits between two "....DOS Free" areas, you may
want to try to reposition the address space occupied by that
adapter by modifying the DIP switch or jumper settings on the
card.
Having one large free memory block is better than two smaller
ones because TSR's and device drivers almost always require more
memory during initialization than once installed. In other
words, neither of the two smaller blocks may be large enough for
the installation, but might if they were combined.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 25
CHAPTER 7 - USE WITH OTHER SOFTWARE
7.1 Microsoft's FASTOPEN and MODE programs
The FASTOPEN and MODE programs that come with MS-DOS are TSR's
and as such may be loaded into upper memory with HIGHTSR. Once
installed, each requires very little memory, something on the
order of 10k or less. However, neither will install unless a
lot of memory is available - approximately 50-90k. (The actual
requirement depends partly on command line options; you can
determine the requirement using the /SIZE option of HIGHTSR.)
╔═════════════════════════════════════════════════╗
║ WARNING: Do NOT use the /LOW option of HIGHTSR ║
║ with FASTOPEN or MODE - it won't work and could ║
║ damage data on your disk! ║
╚═════════════════════════════════════════════════╝
The worst part is that if FASTOPEN fails to install itself
successfully, it doesn't issue any error message - it simply
doesn't display the normal "FASTOPEN installed" sign-on
message. Moral: Let FASTOPEN and MODE be the first TSR's that
are installed into High Memory in your AUTOEXEC.BAT file so that
they get access to the maximum amount of memory.
The second hassle with these two TSR's is that they cannot be
removed by using the advanced utilities HIGHMARK and HIGHUNDO.
Evidently they modify memory other than that tracked by HIGHMARK
(the interrupt vector table and that memory allocated to them).
7.2 Microsoft's SHARE program
MS-DOS 4 installs the SHARE program automatically if you have a
hard disk which is greater than 32 MB in a single partition. It
does this without asking because it is otherwise possible to
corrupt the data on the disk when running programs that use the
old File Control Block (FCB) approach to access files.
Unfortunately, some internal parts of MS-DOS 4.0 also still use
FCB's! So don't try to prevent SHARE from being loaded by
removing it from your system! If MS-DOS can't find it, you'll
get a warning message during the boot saying that "SHARE should
be loaded for large media". You could load it during
AUTOEXEC.BAT processing, but you'll still get the warning
because the check occurs during CONFIG.SYS processing.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 26
┌─────────────────────────────────────────────────┐
│ NOTE: Version 5 of MS-DOS has corrected this │
│ problem and no longer loads SHARE automatically │
│ regardless of the size of your hard disk. │
└─────────────────────────────────────────────────┘
So how can you load this TSR into upper memory without getting
the warning? MS-DOS recently introduced the "INSTALL="
directive that allows TSR's to be installed during CONFIG.SYS
processing. Programs that Microsoft suggests be loaded in this
manner include FASTOPEN, KEYB, NLSFUNC, and SHARE. For example:
INSTALL=C:\DOS\SHARE.EXE
The above command, however, causes SHARE to be loaded down in
conventional memory. to get it into upper memory, use:
INSTALL=HIGHTSR.EXE C:\DOS\SHARE.EXE
╔═════════════════════════════════════════════════╗
║ WARNING: Do NOT use the /LOW option of HIGHTSR ║
║ with SHARE - it won't work and could damage ║
║ data on your disk! ║
╚═════════════════════════════════════════════════╝
7.3 Microsoft's MS-DOS 5.0
With the introduction of MS-DOS 5.0, Microsoft has added
extensive support for loading software into high memory. This
includes not only device drivers and TSRs, but also the MS-DOS
disk buffers, the master environment, and most of the operating
system itself.
Most of this capability requires the use of an Upper Memory
Block (UMB) provider such as Key Software Products'
HIGHUMM.SYS. Although the MS-DOS 5.0 version of EMM386 now
provides such support, there are several disadvantages to using
it instead of The Last Byte Memory Manager to load software
high:
1. EMM386 requires a 386 or better processor.
(HIGHUMM does not.)
2. EMM386 requires that HIMEM.SYS be loaded first.
(HIGHUMM does not. However, HIMEM is also needed
to load the operating system itself into extended
memory; The Last Byte Memory Manager allows you to
load HIMEM into upper memory using HIGHDRVR.)
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 27
3. Using HIMEM and EMM386 as the basis of UMB support
requires that both be loaded into conventional
memory.
4. EMM386 puts the processor into protected mode,
adding an instruction execution time penalty of
about 5%.
There are two basic approaches that you can take to load
software into upper memory using MS-DOS 5.0 and The Last Byte
Memory Manager. The first of these is to install HIGHUMM and
use the 'DEVICEHIGH' and 'LOADHIGH' commands introduced in
MS-DOS 5.0; the other is to use HIGHDRVR and HIGHTSR.
We recommend the latter approach because HIGHDRVR and HIGHTSR
provide a richer set of options for controlling the load high
process.
7.3.1 Using DEVICEHIGH and LOADHIGH
To use this approach, your CONFIG.SYS file should contain the
following lines:
DOS=HIGH,UMB
DEVICE=LASTBYTE.SYS {and any options}
DEVICE=HIGHDRVR.SYS C:\DOS\HIMEM.SYS
DEVICE=HIGHUMM.SYS {and any options}
Then you can use the MS-DOS 5.0 DEVICEHIGH command in additional
lines of your CONFIG.SYS file to load your other device drivers
into upper memory, as in:
DEVICEHIGH={device driver to be loaded high}
DEVICEHIGH={device driver to be loaded high}
. . .
DEVICEHIGH={device driver to be loaded high}
With this CONFIG.SYS file, your AUTOEXEC.BAT file may load TSRs
high using the MS-DOS 5.0 LOADHIGH command as in:
LOADHIGH C:\DOS\PRINT
7.3.2 Using HIGHDRVR and HIGHTSR
The second approach is to use the HIGHDRVR and HIGHTSR utilities
of The Last Byte Memory Manager in the normal manner. To use
this approach, your CONFIG.SYS file should contain the following
lines:
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 28
DOS=HIGH
DEVICE=LASTBYTE.SYS {and any options}
DEVICE=HIGHDRVR.SYS C:\DOS\HIMEM.SYS
Then you can use HIGHDRVR in additional lines of your CONFIG.SYS
file to load your other device drivers into upper memory, as in:
DEVICE=HIGHDRVR.SYS {device driver to be loaded high}
DEVICE=HIGHDRVR.SYS {device driver to be loaded high}
. . .
DEVICE=HIGHDRVR.SYS {device driver to be loaded high}
With this CONFIG.SYS file, your AUTOEXEC.BAT file should load
TSRs high using HIGHTSR as in:
HIGHTSR C:\DOS\PRINT
7.4 Microsoft Windows
In general, The Last Byte Memory Manager has a high degree of
compatibility with Windows 3.0 and 3.1. If you are having
trouble running Windows, first be sure that your system is
properly configured so that it runs without The Last Byte Memory
Manager installed. If you have isolated the problem to their
combination, then perhaps the following information will help to
correct the problem:
7.4.1 Modifying the Windows SYSTEM.INI File
With Windows running in 386 enhanced mode, LASTBYTE.SYS and
Windows will both try to use the upper memory area, thus
creating a conflict. To avoid the conflict, you must ask
Windows to not use this region. This can be done with a few
configuration options in the [386Enh] section of the Windows
SYSTEM.INI file:
EMMExclude=A000-FFFF
HighFloppyReads=no
DualDisplay=yes
SystemROMBreakPoint=no
If you have used the EXCLUDE option of LASTBYTE.SYS to disable
any region of the upper memory, then Windows may be told it is
ok to use that area. For example, if LASTBYTE.SYS is loaded
using the line:
DEVICE=LASTBYTE.SYS EXCLUDE=D000:64
then you may use the following configuration option (in addition
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 29
to the EMMExclude option above) in your SYSTEM.INI file:
EMMInclude=D000-DFFF
The EMMInclude option will take precedence over the EMMExclude
option when the two overlap, as above.
7.4.2 Positioning an EMS Page Frame
If you are using the Real or Standard modes of Windows, you may
have installed an EMS device driver for those applications that
need expanded memory. In an attempt to reduce fragmentation of
upper memory, it is useful to position the EMS Page Frame either
at the bottom or top of an otherwise empty region of upper
memory. However, if you have used the DOS=F000:32 option to
gain another 32k of DOS memory, don't position your EMS Page
Frame at E800 - Windows will not run with it any higher than
E000.
The Enhanced 386 mode of Windows will automatically emulate
expanded memory for those applications that require it.
Unfortunately, Windows ignores the EMMExclude option and
positions the EMS page frame in upper memory. If the same 64k
area is used by The Last Byte Memory Manager for something else,
your system may hang. To correct the problem, add an
"EMSPageFrame=nnnn" option in your SYSTEM.INI file to tell
Windows where to put the page frame, combined with an
"EXCLUDE=nnnn:64" option on the LASTBYTE.SYS command line to
keep it from using this area.
7.4.3 "Unsupported Data Configuration"
The 386 Enhanced mode of Windows 3.0 (not 3.1) has a restriction
that it cannot run when certain types of software have been
loaded high. When this happens, Windows will terminate and
display the error message, "Unsupported Data Configuration".
This only happens in 386 Enhanced mode, and is not related in
particular to use of The Last Byte Memory Manager.
Device drivers that are known to load high without this problem
include HIMEM.SYS, MOUSE.SYS, SETVER.SYS, ANSI.SYS, and all the
Key Software Products device drivers. A device driver and a TSR
known to cause this problem are EGA.SYS and DOSKEY.COM. If you
are experiencing this error message, you can either run Windows
in another mode, or try modifying your CONFIG.SYS and
AUTOEXEC.BAT files to locate and remove the offending software.
Microsoft has removed this restriction in version 3.1 of
Windows.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 30
7.4.4 HIGHMEM and Windows 386 Enhanced Mode
MS-DOS applications run from inside Windows 3.0 are given their
own "virtual" address space of 640k. Windows tells the
processor to map memory references in this space to the
particular 640k of physical memory which has been allocated to
the application. References outside this range are considered
invalid and thus return garbage. Since HIGHMEM is a program
that inspects upper memory between 640k and 1 meg, there's no
way it can execute properly in this context. HIGHMEM will
behave normally outside of Windows.
7.5 HyperWare's HyperDisk
HyperDisk is a shareware disk caching utility. If you use its
"XS" option to load itself into the 48k block starting at E400,
be sure to exclude this area by using the following option on
the LASTBYTE.SYS command line:
DEVICE=LASTBYTE.SYS EXC=E400:48
A better approach is to use either HIGHDRVR or HIGHTSR (as
appropriate) to load HyperDisk high (without HyperDisk's "XS"
option). This method guarantees that the minimum amount of
upper memory will be used.
HyperDisk can be downloaded from HyperWare's BBS at (615)
864-6871, or obtained directly from:
HyperWare
RR#1, Box 91
Pall Mall, TN 38577
Voice: (615) 864-6868
FAX: (615) 864-6870
7.6 J.P. Software's 4DOS
4DOS is a shareware replacement for COMMAND.COM. HIGHUMM.SYS
may be used to move the 4DOS command processor and its master
environment into "Upper Memory Blocks" (UMB's) in the upper
memory area, thus reducing the amount of conventional memory
below 640k used by 4DOS from 3.4k bytes to 256 bytes.
First you must install HIGHUMM.SYS as described earlier in this
manual. Then add a "SHELL=" line to CONFIG.SYS for 4DOS,
including the options /U (to place the command processor in an
UMB) and /E:512U (to place the master environment in an UMB).
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 31
The value 512 is of course only an example - other environment
sizes may be specified. You may also want to specify these
options for secondary shells in the 4DSHELL environment
variable. Consult the 4DOS documentation for further details.
4DOS may be downloaded from Channel 1 BBS at (617) 354-8873, or
obtained directly from:
J.P. Software CompuServe: 75300,210
P.O. Box 1470 BIX: "trawson"
E. Arlington, MA 02174 Internet, Bitnet, etc:
Voice: (617) 646-3975 75300.210@compuserve.com
Fax: (617) 646-0904
7.7 David Hamilton's BUFFIT
There's a very nice shareware scroll-back TSR called BUFFIT that
saves lines of text that have been scrolled off the top of the
screen and allows you to pull them back down for review. One of
the advantages of version 3.0 and later of BUFFIT is that it
will load itself entirely into a UMB provided by HIGHUMM.SYS,
thus using no conventional memory at all.
To install BUFFIT into upper memory, first you must install the
HIGHUMM.SYS device driver by inserting the following lines in
your CONFIG.SYS file:
DEVICE=LASTBYTE.SYS {and any LASTBYTE options}
DEVICE=HIGHUMM.SYS
Then all you have to do is reboot your computer and run BUFFIT
from the command line, or else add it to your AUTOEXEC.BAT
file.
BUFFIT is available from a number of BBS's, usually under the
filename BUFFIT30.ZIP.
7.8 Charles Lazo's WAS
On a computer with no expanded memory, you might want to use
HIGHEMS3 to provide some Expanded Memory for Charles Lazo's
scroll-back TSR, WAS.COM. This utility saves lines of text that
have been scrolled off the top of the screen and allows you to
pull them back down for review. WAS is available from a number
of BBS's, usually under the filename WAS062.ZIP.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 32
7.9 Philip Gardner's DOSMAX
DOSMAX is a set of utilities that compliment The Last Byte
Memory Manager by moving all of the DOS "subsegments" (BUFFERS,
FILES, FCBS, LASTDRIVE, STACKS, etc.), COMMAND.COM, and the DOS
kernel into Upper Memory Blocks provided by HIGHUMM. Set up
your CONFIG.SYS file as follows:
DOS=HIGH
DEVICE=C:\DOSMAX\STOPMAX.SYS
DEVICE=C:\TLBMM\LASTBYTE.SYS
DEVICE=C:\TLBMM\HIGHDRVR.SYS C:\DOSMAX\DOSMAX.EXE
DEVICE=C:\TLBMM\HIGHDRVR.SYS C:\DOS\HIMEM.SYS
DEVICE=C:\TLBMM\HIGHUMM.SYS /REPLACE
If you wish, you can eliminate the use of STOPMAX.SYS by
appending the /I+ or /B+ option to the DOSMAX.EXE command line.
Using the full pathname of DOSMAX.EXE (i.e.,
C:\DOSMAX\DOSMAX.EXE) is very important. The resident stub must
be able to exec DOSMAX.EXE at the proper time, and this requires
the full path to DOSMAX.EXE.
DOSMAX may be obtained from:
Philip B. Gardner
10461 Lever St.
Circle Pines, MN 55014
(612) 785-9439
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 33
APPENDIX 1 - HOW TO REACH US
The Key Software Products telephone (415-364-9847) is shared by
our BBS, FAX, and voice mail answering system. Approximate
hours of operation are:
Voice mail and FAX: 8am - 5pm PST (weekdays)
BBS system: 5pm - 8am PST (24 hrs on weekends)
BBS Parameters: 1200/2400/9600/14400 baud (v.32bis/v.42bis)
8 data bits, No Parity
If your call is answered by the voice mail system, it can take a
message that will be automatically forwarded to someone who can
return your call as soon as possible. In addition, it offers a
touch-tone driven menu of useful information about our product.
To send us a FAX, follow the following steps:
Step 1: You'll be greeted by out Voice Mail system
which will prompt you to press 1 if you have
a touch-tone phone.
Step 2: Press 1. You'll then hear a menu that prompts
you to press 5 to send a FAX.
Step 3: Press 5. In a few seconds, you'll hear a FAX
tone; press start on your FAX machine.
That's all there is to it. Be sure to include your FAX number
for the reply which will be sent back to you in one or two
days.
If you have access to electronic mail, you can send us a message
via any of the following:
On COMPUSERVE, send mail to:
>Internet:ksp!dan.lewis@ames.arc.nasa.gov
On PRODIGY, send mail to: VGDC59A
On INTERNET, UUCP, or BITNET, send mail to:
ksp!dan.lewis@ames.arc.nasa.gov
On FIDONET, send mail to: UUCP
1st line of message: To: ksp!dan.lewis@ames.arc.nasa.gov
On MCI,
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 34
At the "To:" prompt enter: DAN LEWIS (EMS)
At the "EMS:" prompt enter: Internet
At the "Mbx:" prompt enter: ksp!dan.lewis@ames.arc.nasa.gov
On APPLELINK, send mail to:
ksp!dan.lewis@ames.arc.nasa.gov@dasnet#
On TELENET's Telemail Service:
Send to: [INTERMAIL/USCISI]TELEMAIL/USA
1st line of message: Forward: ARPA
2nd line of message: To: ksp!dan.lewis@ames.arc.nasa.gov
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 35
APPENDIX 2 - ACKNOWLEDGEMENTS
The Last Byte Memory Manager wouldn't exist without all the
companies that manufacture the shadow ram memory controller
chips, and who have provided techinical information on how to
program their configuration registers. If you know of a memory
controller chip we haven't included, please let us know and we
will try to add it.
The Last Byte Memory Manager consists of almost a megabyte of
source code, written mostly in C with a sprinkling of assembly
language, and compiled using version 3.1 of the DeSmet/C-Ware C
compiler. We are grateful for the simplicity, flexibility, and
speed of this compiler, as well as the generous support provided
by Joel and Susan Farley of C-Ware Corporation.
The Last Byte Memory Manager could not have been created without
the gracious support of many people. We wish to thank the
following individuals who helped to test beta versions or
offered useful suggestions for new features: Ron Cohen, J.B.
Compton, David Durgee, Philip Gardner, Mike Hagerty, Scott
Jordahl, Alan Lambert, Rob Nee, Kevin Parris, Dan Proctor,
Graham Robertson, Ken Sanquist, Tony Sheehan, Peter Summers,
Steve Hodsdon, Anthony Cox, My Phung, Martin Beckmann, and Prof.
Timo Salmi (of the University of Vaasa, Finland).
Thank's also go to Tom Rawson of J. P. Software for providing a
copy of 4DOS, to Sue Nageotte of Digital Research for providing
a copy of DR DOS, to Philip Gardner for providing a copy of
DOSMAX, and to Pat Gelsinger of Intel Corporation for lending
his intimate knowledge of the 80x86 instruction sets. And
finally, a special thanks to Serge Caron, Roger Cross, and
Philip Gardner for their suggestions, technical advice,
patience, and friendship.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
Aug 11, 1992 THE LAST BYTE MEMORY MANAGER (tm) 36
APPENDIX 3 - LIMITED WARRANTY
This software is provided 'as is' without warranty of any kind,
either expressed or implied, including, but not limited to the
implied warranties of merchantability and fitness for a
particular purpose. The entire risk as to the quality and
performance of the program is with you.
Some states do not allow the exclusion of implied warranties, so
the above exclusions may not apply to you. This warranty gives
you specific legal rights and you may also have other rights
which vary from state to state.
Key Software Products has taken due care in preparing the
documentation and software included in The Last Byte Memory
Manager to ascertain their correctness and effectiveness.
However, Key Software Products does not warrant that operation
of this software will be uninterrupted or error free. In no
event shall Key Software Products be liable for incidental or
consequential damages in connection with or arising out of the
furnishing, performance, or use of this software.
LICENSE
You MAY use this software on any computer or computers in your
possesion, but on no more than one computer at any given time.
You MAY copy this software into any machine readable or printed
form for backup or modification purposes in support of your use
of the software.
You MAY distribute the original unmodified, unlicensed version
of this software, but you may not charge a fee exceeding $5.00
to cover the cost of duplicating, shipping, and handling. You
may NOT distribute a licensed version of this software.
You may NOT use, copy, modify, sublicense, assign or transfer
this software and its license, or any copy or modification, in
whole or in part, except as expressly provided for in this
license.
Copyright (C) 1990-92, Key Software Products. All Rights Reserved
